Method and system for streaming data from portable storage devices

ABSTRACT

A method and system for streaming data from portable storage devices. Specifically, the disclosed method and system implement iterative data streaming from a portable storage device for remote storage operations, while requiring zero over-provisioning storage space for buffering incoming write operations to the portable storage device.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of and claims priorityunder 35 U.S.C. § 120 to U.S. patent application Ser. No. 17/396,878,titled “Method and System For Streaming Data From Portable StorageDevices” and filed on Aug. 9, 2021, which is a continuation applicationof and claims priority under 35 U.S.C. § 120 to U.S. patent applicationSer. No. 17/067,924, titled “Method and System For Streaming Data FromPortable Storage Devices” and filed on Oct. 12, 2020 (now U.S. Pat. No.11,086,853 issued on Aug. 10, 2021). The entire contents of theseaforementioned applications are herein incorporated herein by reference.

BACKGROUND

Users of computing devices generate and locally store an ever increasingamount of data. In some scenarios, these users may also want to storeanother copy of the data in a different location. Traditional approachesto storing another copy of the data in a different location typicallyresult in a decrease in performance of the computing device and/or anegative user experience while the data is being transferred.

SUMMARY

In general, in one aspect, the invention relates to a method forstreaming data. The method includes receiving, from a host device, adelta generation request, in response to the delta generation request,identifying a first current transaction group identifier, obtaining atransaction group identifier associated with a last successful deltageneration request, identifying a first collection of block sets mappedto a first collection of transaction group identifiers, wherein eachtransaction group identifier of the first collection of transactiongroup identifiers exceeds the transaction group identifier associatedwith the last successful delta generation request, and initiating, tothe host device, a transmission of the first collection of block sets.

In general, in one aspect, the invention relates to a non-transitorycomputer readable medium (CRM). The non-transitory CRM includes computerreadable program code, which when executed by a computer processor,enables the computer processor to receive, from a host device, a deltageneration request, in response to the delta generation request,identify a first current transaction group identifier, obtain atransaction group identifier associated with a last successful deltageneration request, identify a first collection of block sets mapped toa first collection of transaction group identifiers, wherein eachtransaction group identifier of the first collection of transactiongroup identifiers exceeds the transaction group identifier associatedwith the last successful delta generation request, and initiate, to thehost device, a transmission of the first collection of block sets.

In general, in one aspect, the invention relates to a portable storagedevice. The portable storage device includes persistent storage, and acontroller operatively connected to the persistent storage, andprogrammed to receive a delta generation request, in response to thedelta generation request, identify a first current transaction groupidentifier, obtain a transaction group identifier associated with a lastsuccessful delta generation request, identify a first collection ofblock sets residing in the persistent storage and mapped to a firstcollection of transaction group identifiers, wherein each transactiongroup identifier of the first collection of transaction groupidentifiers exceeds the transaction group identifier associated with thelast successful delta generation request, and initiate a transmission ofthe first collection of block sets.

Other aspects of the invention will be apparent from the followingdescription and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows a system in accordance with one or more embodiments of theinvention.

FIG. 2 shows various relationships in accordance with one or moreembodiments of the invention.

FIG. 3 shows a flowchart describing a method for writing data inaccordance with one or more embodiments of the invention.

FIG. 4 shows a flowchart describing a method for streaming data from aportable storage device in accordance with one or more embodiments ofthe invention.

FIG. 5 shows an exemplary scenario in accordance with one or moreembodiments of the invention.

FIG. 6 shows an exemplary computing system in accordance with one ormore embodiments of the invention.

DETAILED DESCRIPTION

Specific embodiments of the invention will now be described in detailwith reference to the accompanying figures. In the following detaileddescription of the embodiments of the invention, numerous specificdetails are set forth in order to provide a more thorough understandingof the invention. However, it will be apparent to one of ordinary skillin the art that the invention may be practiced without these specificdetails. In other instances, well-known features have not been describedin detail to avoid unnecessarily complicating the description.

In the following description of FIGS. 1-6 , any component described withregard to a figure, in various embodiments of the invention, may beequivalent to one or more like-named components described with regard toany other figure. For brevity, descriptions of these components will notbe repeated with regard to each figure. Thus, each and every embodimentof the components of each figure is incorporated by reference andassumed to be optionally present within every other figure having one ormore like-named components. Additionally, in accordance with variousembodiments of the invention, any description of the components of afigure is to be interpreted as an optional embodiment which may beimplemented in addition to, in conjunction with, or in place of theembodiments described with regard to a corresponding like-namedcomponent in any other figure.

Throughout the application, ordinal numbers (e.g., first, second, third,etc.) may be used as an adjective for an element (i.e., any noun in theapplication). The use of ordinal numbers is not to necessarily imply orcreate any particular ordering of the elements nor to limit any elementto being only a single element unless expressly disclosed, such as bythe use of the terms “before”, “after”, “single”, and other suchterminology. Rather, the use of ordinal numbers is to distinguishbetween the elements. By way of an example, a first element is distinctfrom a second element, and a first element may encompass more than oneelement and succeed (or precede) the second element in an ordering ofelements.

In general, embodiments of the invention relate to a method and systemfor streaming data from portable storage devices. Specifically, one ormore embodiments of the invention implement iterative data streamingfrom a portable storage device to a remote storage system, whilerequiring zero over-provisioning storage space for buffering incomingwrite operations to the portable storage device.

That is, conventionally, in order to store data changes that areatomically made in a portable storage device to a remote storage system,the portable storage device is required to cease any incoming writeoperations transpiring during a period of time during which the datachanges are stored on the remote storage device. Often times, tomitigate the loss of write-data requested to be written into theportable storage device, which may result from the stoppage of anytranspiring write operations, the portable storage device may beconfigured with a limited, over-provisioned storage space used to bufferthe incoming write-data until the storage of aforementioned data changesto the remote storage system completes. There are scenarios, however,when an such remote storage operation may take longer to complete thanthe time that the portable storage device uses to consume the limited,over-provisioned storage space with buffered incoming write-data. Insuch scenarios, loss of write-data submitted to the portable storagedevice, after full-consumption of the limited, over-provisioned storagespace, is inevitable.

FIG. 1 shows a system in accordance with one or more embodiments of theinvention. The system (100) may include a remote storage system (102)operatively connected to a host device (104) through a network (notshown). In turn, the host device (104) may operatively connect to astorage device (112) through a physical connection (120). Each of thesesystem (100) components is described below.

In one embodiment of the invention, the remote storage system (102) mayrepresent a data backup, archiving, and/or disaster recovery storagesystem. The remote storage system (102) may be implemented using one ormore servers (not shown)—each including, but not limited to, one or morearrays of persistent storage. Further, each server may represent aphysical server, which may reside in a datacenter, or a virtual server,which may reside in a cloud computing environment. Additionally oralternatively, the remote storage system (102) may be implemented usingone or more computing systems similar to the exemplary computing systemshown in FIG. 6 .

In one embodiment of the invention, the network (not shown) (e.g., alocal area network (LAN), a wide area network (WAN) such as theInternet, a mobile network, any other network type, or a combinationthereof), operatively connecting the remote storage system (102) and thehost device (104), may be implemented using any combination of wiredand/or wireless connections. The network may encompass variousinterconnected, network-enabled devices (e.g., switches, routers,gateways, etc.) that may facilitate communications between the remotestorage system (102) and the host device (104). Further, the remotestorage system (102) and the host device (104) may communicate with oneanother using any combination of wired and/or wireless communicationprotocols.

In one embodiment of the invention, the host device (104) may representany physical appliance or computing system configured to receive,generate, process, store, and/or send data. Examples of the host device(104) may include, but are not limited to, a desktop computer, a tabletcomputer, a laptop computer, or any computing system similar to theexemplary computing system shown in FIG. 6 . Furthermore, the hostdevice (104) may include one or more applications (106), at least onefile system (108), and at least one driver (110). Each of these hostdevice (104) subcomponents is described below.

In one embodiment of the invention, an application (106) may refer to acomputer program that may execute on the underlying hardware of the hostdevice (104). Generally, an application (106) may be configured toperform one or more functions, tasks, and/or activities instantiated bya user of the host device (104). Further, towards performing theseoperations, an application (106) may include functionality to requestand consume host device (104) resources (not shown) (e.g., computerprocessors, memory, storage, virtualization, network bandwidth, etc.) byway of service calls to the host device (104) operating system (OS) orkernel (not shown). An application (106) may also include functionalityto request and consume resources, via service calls to the host device(104) OS or kernel, from external devices such as the storage device(112) and the remote storage system (102), which may operatively connectto the host device (104). One of ordinary skill will appreciate that anapplication (106) may perform other functionalities without departingfrom the scope of the invention. Examples of an application (106) mayinclude, but are not limited to, a word processor, a multimedia creationprogram, a multimedia editing program, an email client, a databaseclient, a web browser, a file viewer, an image editor, a simulator, acomputer game, or another computer executable program.

In one embodiment of the invention, an application (106) may utilizeservice calls to read and/or write information from/to persistent (i.e.,non-volatile) storage on the host device (104), the storage device(112), and/or the remote storage system (102). To enable these servicecalls, the host device (104) OS or kernel may implement and expose oneor more file systems (108) to a user and, accordingly, to anyapplication (104). Each file system (106) may represent one or more dataobjects or structures that collectively index and track various forms ofa given subset of information stored on the host device (104), thestorage device (112), and/or the remote storage system (102). By way ofan example, a file system (108) may be implemented through at least adirectory and an inode table, which may map filenames to disk blocks orcells in the physical storage on which the binary data corresponding tothe filenames may reside. The invention is not limited to theaforementioned example.

In one embodiment of the invention, a file system (108) may interactwith one or more drivers (110) to retrieve and/or store data from/intopersistent storage on the host device (104), the storage device (112),and/or the remote storage system (102). A driver (110) for a givenhardware device may refer to a special computer program that enables theoperation or control of the given hardware device. More specifically, adriver (110) may serve as a translator between the instructing software(e.g., host device OS, file system (106), etc.) and the given hardwaredevice, thereby facilitating the translation of the former'sinstructions into a language that the given hardware device cancomprehend and act upon.

In one embodiment of the invention, the storage device (112) may relateto any portable, direct-attached storage (DAS) system. A DAS system mayrepresent dedicated digital storage, which directly connects to acomputing system—i.e., the host device (104)—rather than through anetwork (e.g., to the remote storage system (102)). The storage device(112) may be implemented, for example, as an enclosure including one ormany non-transitory computer readable media for retaining digital datain whole or in part, and temporarily and/or permanently. Should thestorage device (112) include multiple non-transitory computer readablemedia (e.g., flash storage, optical storage, magnetic storage,solid-state storage, etc.), the media may be of a common type or ofvarying types. Furthermore, the storage device (112) may include acontroller (114), volatile storage (116), and one or more persistentstorage media devices (118). Each of these storage device (112)subcomponents is described below.

In one embodiment of the invention, the controller (114) may representan integrated circuit configured for processing instructions (e.g.,computer readable program code). These instructions may include, but arenot limited to, data reading and/or writing operations from the hostdevice (104) directed to retrieving and/or storing information from/intothe array of persistent storage media devices (118). Further, based onthese instructions, the controller (114) may include functionality tointeract with the volatile storage (116) and/or the array of persistentstorage media devices (118) to perform the steps outlined in FIGS. 3 and4 , below. One of ordinary skill will appreciate that the controller(114) may perform other functionalities without departing from the scopeof the invention. Examples of the controller (114) may include, but arenot limited to, a micro-controller, a micro-processor, afield-programmable gate array (FPGA), a central processing unit (CPU),or any other instructions-processing integrated circuit.

In one embodiment of the invention, the volatile storage (116) mayrepresent computer memory that requires power to maintain storedinformation. That is, volatile storage (116) may refer to storagetechnology capable of retaining information temporarily. Examples ofvolatile storage (116) may include, but are not limited to, staticrandom access memory (SRAM) and dynamic random access memory (DRAM).

In one embodiment of the invention, the persistent storage mediadevice(s) (118) may refer to a collection of non-volatile storage, orstorage technologies that do not require a continuous supply of power toretain information. Accordingly, each persistent storage media device(118) may encompass non-transitory computer readable media on whichdigital information may be stored in whole or in part, and temporarilyand/or permanently. Further, any subset or all of the persistent storagemedia device(s) (118) may or may not be combined in a redundant array ofindependent disks (RAID) configuration for fault tolerance purposes.Examples of persistent (i.e., non-volatile) storage may include, but arenot limited to, optical storage, magnetic storage, NAND Flash Memory,NOR Flash Memory, Magnetic Random Access Memory (M-RAM), Spin TorqueMagnetic RAM (ST-MRAM), Phase Change Memory (PCM), or any other storagedefined as non-volatile Storage Class Memory (SCM).

In one embodiment of the invention, the physical connection (120)between the host device (104) and the storage device (112) may representany tangible cable, or an assembly of wires, configured for inter-devicedata transfer. Examples of the physical connection (120) may include,but are not limited to, a FireWire cable (which is based on IEEE 1394),a serial advanced technology attachment (SATA) (or any variant thereof)cable, a universal serial bus (USB) (or any variant thereof) cable, asmall computer system interface (SCSI) (or any variant thereof) cable, aserial-attached SCSI (SAS) (or any variant thereof) cable, a Thunderboltcable, or any other cabling solution for storage device (112)interfacing.

While FIG. 1 shows a configuration of components, other system (100)configurations may be used without departing from the scope of theinvention.

FIG. 2 shows various relationships in accordance with one or moreembodiments of the invention. These relationships may include mappingsassociating a storage device (200) to one or more namespaces (202,202A-202N), a persistent storage media device (204) to one or more blocksets (206), a namespace (202, 202A-202N) to the block set(s) (206), anda transaction group (208) to a block set (206). Each of these mappingsis described below.

In one embodiment of the invention, a storage device (200) may retaindigital data on one or many non-transitory computer readable mediadisposed therein, where the digital data may pertain to one or morenamespaces (202, 202A-202N). A namespace (202, 202A-202N) may refer toan abstraction used to isolate a subset or partition of the pooledstorage space, across the non-transitory computer readable media, whichmay be dedicated to a given user of a host device (not shown) (describedabove) (see e.g., FIG. 1 ), a given operating system (OS) installed onthe host device, or a given file system implemented on the host device.

Further, in one embodiment of the invention, each namespace (202,202A-202N) may define a hierarchical naming and organizational frameworkfor managing data retained within the given subset of the pooled storagespace with which the namespace (202, 202A-202N) may be associated. Byway of an example, each namespace (202, 202A-202N) may define: (i) thecharacter set (e.g., letters, numbers, symbols, etc.) and maximum lengthof characters used for data naming; (ii) the logical structure (e.g.,directories, sub-directories, and filenames) used for data organization;and (iii) the metadata structure (e.g., disk block usage andavailability, creation date, last modification date, disk blocklocations, disk subdivisions used, etc.) used for data description andsupport. Moreover, each namespace (202, 202A-202N) may be referencedusing a unique namespace identifier.

In one embodiment of the invention, a persistent storage media device(204), of the storage device (200) (described above) (see e.g., FIG. 1), may represent a physical (i.e., hardware) disk for storing data.Further, the storage space on a physical disk may be subdivided intonumerous data blocks—each of which may function as a smallest unit ofstorage space configured to be addressed and accessed by the storagedevice controller. A group of these data blocks, which may or may not becontiguous, across one or many physical disks, may be referred to as ablock set (206).

In one embodiment of the invention, namespaces (202, 202A-202N), asdescribed above, may isolate partitions of the pooled storage space,across the one or many persistent storage media device(s) (204), fordedicated use by given users, operating systems, and/or file systems.Each partition, accordingly, may utilize various non-contiguous datablocks, addressed and accessed in the form of one or more block sets(206) (described above), for storing data respective to their associatednamespace (202, 202A-202N).

In one embodiment of the invention, a transaction group (208) mayreference a changed data stream, or a sequence of block sets (206) ofwhich each may include any granularity of change amongst theirconstituent group of data blocks. Changes to any data block may, forexample, result from updates to or overwriting of existing data storedin a data block occupied by live data (i.e., a live cell); or fromwriting data into an available data block unoccupied by live data.Further, each transaction group (208) may be identified through a uniquetransaction group identifier.

In one embodiment of the invention, transaction group identifiers may beexpressed as positive integers, which may be generated in successive,ascending order—e.g., 1, 2, 3, 4, . . . , N. The generation of eachsuccessive transaction group identifier may be triggered by anyconfigurable criterion. For example, each successive transaction groupidentifier may be generated following the elapsing of a configurabletime interval ΔT—i.e., at time T0, the transaction group identifier maybe 1; at time T0+ΔT, the transaction group identifier may be 2; at timeT0+2·ΔT, the transaction group identifier may be 3; and so forth. By wayof another example, each successive transaction group identifier may begenerated following a configurable threshold count C of block sets thathave exhibited changes—i.e., a counter may be set to 1 and incrementsfor each changed block set at the implementation time of the changes;eventually, a first collection of changed block sets [BS-1, BS-2, BS-3,. . . , BS-C] is identified, where each changed block set may be trackedand enumerated by a successive counter value up until C is reached,where the first collection of changed block sets may each be mapped totransaction group identifier 1; the counter resets to 1 and incrementsagain for each changed block set at the implementation time of thechanges; eventually, a second collection of changed block sets [BS-1,BS-2, BS-3, . . . , BS-C] is identified, where each changed block setmay be tracked and enumerated by a successive counter value up until Cis reached, where the second collection of changed block sets may eachbe mapped to transaction group identifier 2; and so forth. The inventionis not limited to the aforementioned methods for generating transactiongroups.

FIG. 3 shows a flowchart describing a method for writing data inaccordance with one or more embodiments of the invention. The varioussteps outlined below may be performed by the controller of the storagedevice (see e.g., FIG. 1 ). Further, while the various steps in theflowchart are presented and described sequentially, one of ordinaryskill will appreciate that some or all steps may be executed indifferent orders, may be combined or omitted, and some or all steps maybe executed in parallel.

Turning to FIG. 3 , in Step 300, a write request is received from a hostdevice (described above) (see e.g., FIG. 1 ). In one embodiment of theinvention, the write request may include write-data, or any granularityof digital data requested to be written into persistent storage on thestorage device, as well as a unique namespace identifier assigned to agiven namespace.

In Step 302, one or more block sets is/are selected from amongst anavailable block set pool. In one embodiment of the invention, theavailable block set pool may refer to a collection of available blocksets—each of which, including the selected block set(s), may represent agroup of non-contiguous data blocks, across the persistent storage ofthe storage device, which may be available or unoccupied by live data.Live data, in turn, may refer to any granularity of digital data formingone or more active data files in whole or in part.

In Step 304, the write-data (obtained via the write request received inStep 300) is written into the block set(s) (selected in Step 302).Further, in one embodiment of the invention, the selected block set(s)may be associated with a given transaction group (described above) (seee.g., FIG. 2 ) designated for a given time interval or group of changedblock sets, or more specifically, a unique transaction group identifierassigned to the given transaction group. The selected block set(s) mayalso be associated with the above-mentioned given namespace, or morespecifically, the unique namespace identifier (further obtained via thewrite request received in Step 300) assigned to the given namespace.

The method described above with respect to FIG. 3 may be performed inconcurrently with one or more step in FIG. 4 . As a result, the data maybe stored in the storage device while the storage device is servicing adelta generation request. In this manner, the storage device maycontinue to service write requests while concurrently servicing deltageneration requests.

FIG. 4 shows a flowchart describing a method for streaming data from aportable storage device in accordance with one or more embodiments ofthe invention. The various steps outlined below may be performed by thecontroller of the storage device (see e.g., FIG. 1 ). Further, while thevarious steps in the flowchart are presented and described sequentially,one of ordinary skill will appreciate that some or all steps may beexecuted in different orders, may be combined or omitted, and some orall steps may be executed in parallel.

Turning to FIG. 4 , in Step 400, a delta generation request is receivedfrom a host device (described above) (see e.g., FIG. 1 ). In oneembodiment of the invention, the delta generation request may include aunique namespace identifier assigned to a given namespace.

In Step 402, a first current transaction group identifier is determined.In one embodiment of the invention, the first current transaction groupidentifier may refer to a most recently generated transaction groupidentifier, at the execution time of Step 402, based on a configuredcriterion governing transaction group identifier generation (see e.g.,FIG. 2 ).

In Step 404, a transaction group identifier, associated with a lastsuccessful delta generation request, is obtained. In one embodiment ofthe invention, the transaction group identifier may refer to atransaction group identifier in existence at the point-in-time duringwhich a last received delta generation request had been marked assuccessful (see e.g., Step 418).

In Step 406, a first collection of block sets is identified. In oneembodiment of the invention, each block set of the first collection ofblock sets may be associated with the unique namespace identifier(obtained via the delta generation request received in Step 400).Further, each block set of the first collection of block sets may map toa transaction group identifier that exceeds (or is greater than) thetransaction group identifier associated with the last successful deltageneration request (obtained in Step 404). The first collection of blocksets may encompass one or more transaction groups.

In Step 408, transmission of the first collection of block sets, to thehost device, is initiated. Transmission of the first collection of blocksets includes sending the blocks in the first collection of block setsto the host device and, upon receipt, the host device (e.g., via anetwork interface) sends the blocked to the remote storage system.

In Step 410, a determination is made as to whether the transmission(initiated in Step 408) has completed. The transmission is determined tobe completed when the all blocks in the first collection of block setsare stored in the remote storage system. In one embodiment of theinvention, if it is determined that the aforementioned transmission iscomplete, then the process proceeds to Step 412. On the other hand, inanother embodiment of the invention, if it is alternatively determinedthat the aforementioned transmission is incomplete, then the processalternatively continues the transmission to the host device.

In Step 412, following the completion of the transmission of the firstcollection of block sets (determined in Step 410), a second currenttransaction group identifier is determined. In one embodiment of theinvention, the second current transaction group identifier may refer toa most recently generated transaction group identifier, at the executiontime of Step 412, based on a configured criterion governing transactiongroup identifier generation (see e.g., FIG. 2 ).

In Step 414, a determination is made as to whether the most recentcurrent (e.g., a second determined in a first execution of Step 412, athird determined in a second execution of Step 412, etc.) transactiongroup identifier differs from the previous current (e.g., a firstdetermined in Step 402, a second determined in the first execution ofStep 412, etc.) transaction group identifier. Accordingly, in oneembodiment of the invention, if it is determined that the most recentand previous current transaction group identifiers mismatch, then theprocess proceeds to Step 416. On the other hand, in another embodimentof the invention, if it is alternatively determined that the most recentand previous current transaction group identifiers match, then theprocess alternatively proceeds to Step 418.

In Step 416, following the determination (in Step 414) that the mostrecent current (e.g., a second determined in a first execution of Step412, a third determined in a second execution of Step 412, etc.)transaction group identifier mismatches the previous current (e.g., afirst determined in Step 402, a second determined in the first executionof Step 412, etc.) transaction group identifier, a second (i.e., orthird, fourth, etc. dependent on the iteration) collection of block setsis identified. In one embodiment of the invention, each block set of thesecond, etc. collection of block sets may be associated with the uniquenamespace identifier (obtained via the delta generation request receivedin Step 400). Further, each block set of the second, etc. collection ofblock sets may map to a transaction group identifier that exceeds (or isgreater than) the first (i.e., or second, third, etc. dependent on theiteration) current transaction group identifier. The second, etc.collection of block sets may encompass one or more transaction groups.

In one embodiment of the invention, for clarification of theabove-mentioned iterations, following the identification of the secondcollection of block sets (in a first execution or iteration of Step416), the process proceeds to a second execution/iteration of Step 408,where a transmission of the second collection of block sets, to the hostdevice, is initiated. Further, upon completion of the aforementionedtransmission, the process proceeds to a second execution/iteration ofStep 412, where a third current transaction group identifier isdetermined and is used, in conjunction with the second currenttransaction group identifier (determined in the firstexecution/iteration of Step 412), to enact a second execution/iterationof either Step 416 or Step 418. The path of steps, from Step 416 to Step408 to Step 410 to Step 412 to Step 416 again, may cycle for one or moreiterations until a most recent current (e.g., second, third, etc.)transaction group identifier matches a previous current (e.g., first,second, etc.) transaction group identifier.

In Step 418, following the alternative determination (in Step 414) thatthe most recent current (e.g., a second determined in a first executionof Step 412, a third determined in a second execution of Step 412, etc.)transaction group identifier matches the previous current (e.g., a firstdetermined in Step 402, a second determined in the first execution ofStep 412, etc.) transaction group identifier, the write request(received in Step 500) is marked as a successful delta generationrequest and, accordingly, replaces the previous last successful deltageneration request as the most recent last successful delta generationrequest.

In one embodiment of the invention, the method shown in FIG. 4 continuesuntil the transaction group identifier does not change between the step408 and step 414. However, if the amount of data being written (inaccordance with FIG. 3 ) is at a rate that results in the transactiongroup identifier continually changing over successive iterations betweenthe times Step 408 and Step 414 are performed, then the processing ofthe default generation request may be halted (or otherwise terminated)and the host device and/or the user of the host device may be informedthat the delta generation request has failed. In such scenarios, theuser and/or host device may attempt to perform the method shown in FIG.4 at a latter point in time. For example, if Step 414 is performed morethan four times (retry threshold) during the servicing of a single deltageneration request, then method shown in FIG. 4 may be halted (orotherwise terminated). The retry threshold is not limited to theaforementioned example.

In one embodiment of the invention, if the delta generation request ishalted, then the controller and/or the host device (or process executingthereon) may monitor the rate at which write requests are being issuedto the storage device (also referred to as the write rate) and, when thewrite rate is below a pre-determined value (also referred to as thewrite rate threshold), the method shown in FIG. 4 may be automaticallyinitiated. The automatic initiation may occur after a prior attempt toperform the method shown in FIG. 4 is halted (or terminated).

Additionally, or alternatively, the storage device may be configured tomonitor the write rate and then automatically initiate (or prompt a userof the host device to initiate) the method shown in FIG. 4 when thewrite rate is below a write rate threshold. Other factors (in additionto the write rate and write rate threshold) may be used to automaticallyinitiate the method shown in FIG. 4 without departing from theinvention.

By implementing the method shown in FIGS. 3 and 4 , various embodimentsof the invention enable the storage of a copy of the data that iscurrently stored on the storage device in a remote storage device.However, the methods shown in FIGS. 3 and 4 can only guarantee that acopy of the data will, at some point in the future (assuming the methodin FIG. 4 is not halted or terminated), be stored on the remote storagesystem; the methods shown in FIGS. 3 and 4 do not guarantee that aspecific version of the data (i.e., data stored up to a specifictransaction group) will be stored in the remote storage system.

FIG. 5 shows an exemplary scenario in accordance with one or moreembodiments of the invention. The following exemplary scenario,presented in conjunction with components shown in FIG. 5 , is forexplanatory purposes only and not intended to limit the scope of theinvention.

For the exemplary scenario, consider that a delta generation request hasbeen received by a storage device (see e.g., FIG. 1 ) and from a hostdevice physically connected thereto. The delta generation request mayspecify a unique namespace identifier assigned to the given namespace.

Turning to FIG. 5 , following embodiments of the invention, processingof the delta generation request begins with a determination of a firstcurrent transaction group identifier—i.e., TGID 25. Next, a transactiongroup identifier—i.e., TGID 18—is obtained, which is associated with alast successful delta generation request. Thereafter, a first collectionof block sets, mapped to the given namespace, is identified. The firstcollection of blocks sets include block set 0 (BS-0), BS-1, BS-2, BS-3,BS-4, BS-5, BS-6, and BS-7. Further, each block set of the firstcollection of block sets is identified based on their respectivetransaction group identifier at the time (i.e., TGID 19 for BS-0, TGID20 for BS-1, TGID 20 for BS-2, TGID 22 for BS-3, TGID 25 for BS-4, TGID19 for BS-5, TGID 24 for BS-6, and TGID 19 for BS-7) exceeding thetransaction group identifier (i.e., TGID 18) for the last successfuldelta generation request. Through their identification, each block setof the first collection of block sets includes at least one constituentdata block exhibiting a state (e.g., available or occupied), or storingdata (e.g., updated or overwritten), different from their respectivestate or stored data during processing of the last successful deltageneration request.

Following their identification, transmission of the first collection ofblock sets, to the host device, initiates. Upon the completion of thistransmission, a second current transaction group identifier—i.e., TGID29—is determined. Because the second current transaction groupidentifier mismatches the first current transaction group identifier(i.e., TGID 25), a second collection of block sets, mapped to the givennamespace, is identified. The second collection of block sets includeBS-1, BS-4, and BS-7, each of which is identified based on theirrespective transaction group identifier at the time (i.e., TGID 28 forBS-1, TGID 29 for BS-4, and TGID 26 for BS-7) exceeding the firstcurrent transaction group identifier. Through their identification, eachblock set of the second collection of block sets includes at least oneconstituent data block exhibiting a change of state or a change of datastored therein since the identification of the first collection of blocksets.

Following their identification, transmission of the second collection ofblock sets, to the host device, initiates. Upon completion of thistransmission, a third current transaction group identifier—i.e., TGID32—is determined. Because the third current transaction group identifiermismatches the second current transaction group identifier (i.e., TGID29), a third collection of block sets, mapped to the given namespace, isidentified. The third collection of block sets include BS-1, which isidentified based on their respective transaction group identifier at thetime (i.e., TGID 32) exceeding the second current transaction groupidentifier. Through their identification, BS-1 of the third collectionof block sets includes at least one constituent data block exhibiting achange of state or a change of data stored therein since theidentification of the second collection of block sets.

Following their identification, transmission of the third collection ofblock sets—i.e., BS-1—to the host device, initiates. Upon completion ofthis transmission, a fourth current transaction group identifier—i.e.,TGID 32—is determined. This time, because the fourth current transactiongroup identifier matches the third current transaction group identifier(i.e., TGID 32), the received delta generation request is marked assuccessful and replaces the previous last successful delta generationrequest as the most recent last successful delta generation request.Further, the most recent last successful delta generation request isassociated with the fourth current transaction group identifier (i.e.,TGID 32), which may be used in the processing of a future received deltageneration request by the storage device.

FIG. 6 shows an exemplary computing system in accordance with one ormore embodiments of the invention. The computing system (600) mayinclude one or more computer processors (602), non-persistent storage(604) (e.g., volatile memory, such as random access memory (RAM), cachememory), persistent storage (606) (e.g., a hard disk, an optical drivesuch as a compact disk (CD) drive or digital versatile disk (DVD) drive,a flash memory, etc.), a communication interface (612) (e.g., Bluetoothinterface, infrared interface, network interface, optical interface,etc.), input devices (610), output devices (608), and numerous otherelements (not shown) and functionalities. Each of these components isdescribed below.

In one embodiment of the invention, the computer processor(s) (602) maybe an integrated circuit for processing instructions. For example, thecomputer processor(s) may be one or more cores or micro-cores of acentral processing unit (CPU) and/or a graphics processing unit (GPU).The computing system (600) may also include one or more input devices(610), such as a touchscreen, keyboard, mouse, microphone, touchpad,electronic pen, or any other type of input device. Further, thecommunication interface (612) may include an integrated circuit forconnecting the computing system (600) to a network (not shown) (e.g., alocal area network (LAN), a wide area network (WAN) such as theInternet, mobile network, or any other type of network) and/or toanother device, such as another computing device.

In one embodiment of the invention, the computing system (600) mayinclude one or more output devices (608), such as a screen (e.g., aliquid crystal display (LCD), a plasma display, touchscreen, cathode raytube (CRT) monitor, projector, or other display device), a printer,external storage, or any other output device. One or more of the outputdevices may be the same or different from the input device(s). The inputand output device(s) may be locally or remotely connected to thecomputer processor(s) (602), non-persistent storage (604), andpersistent storage (606). Many different types of computing systemsexist, and the aforementioned input and output device(s) may take otherforms.

Software instructions in the form of computer readable program code toperform embodiments of the invention may be stored, in whole or in part,temporarily or permanently, on a non-transitory computer readable mediumsuch as a CD, DVD, storage device, a diskette, a tape, flash memory,physical memory, or any other computer readable storage medium.Specifically, the software instructions may correspond to computerreadable program code that, when executed by a processor(s), isconfigured to perform one or more embodiments of the invention.

While the invention has been described with respect to a limited numberof embodiments, those skilled in the art, having benefit of thisdisclosure, will appreciate that other embodiments can be devised whichdo not depart from the scope of the invention as disclosed herein.Accordingly, the scope of the invention should be limited only by theattached claims.

What is claimed is:
 1. A method for streaming data using a collection ofblock sets, the method comprising: monitoring, during a pause in a deltageneration request received from a host device for the collection ofblock sets, a write rate at which write requests are issued to a storagedevice within a time interval; evaluating the write rate against athreshold write rate value within the time interval; continuing thepause of the delta generation request upon determining that the writerate is at least as high as the threshold write rate value; and resumingthe delta generation request upon determining that the write rate isless than the threshold write rate value.
 2. The method of claim 1,further comprising: monitoring the write rate at which write requestsare issued to the storage device prior to the pause; and initiating thepause in the delta generation request after determining that the writerate is at least as high as the threshold write rate value.
 3. Themethod of claim 1, further comprising: continuing to monitor the writerate at which write requests are issued to the storage device afterresuming the delta generation request; and initiating a second pause inthe delta generation request after determining that the write rate is atleast as high as the threshold write rate value after resuming the deltageneration request.
 4. The method of claim 1, wherein resuming the deltageneration request comprises identifying an updated block set in thecollection of block sets relative to a prior time.
 5. The method ofclaim 4, wherein identifying the updated block set comprises identifyinga transaction group identifier of the updated block set.
 6. The methodof claim 1, wherein the pause in the delta generation request lasts fora period of time that exceeds the interval of time.
 7. The method ofclaim 6, further comprising: terminating, after the period of timewithout resuming the delta generation request, the delta generationrequest.
 8. The method of claim 1, wherein resuming the delta generationrequest is based on receiving a resumption request from the host deviceafter the host device receives a determination that the write rate isless than the threshold write rate value.
 9. A non-transitory computerreadable medium (CRM) comprising computer readable program code, whichwhen executed by a computer processor, enables the computer processorto: monitor, during a pause in a delta generation request received froma host device for the collection of block sets, a write rate at whichwrite requests are issued to a storage device within a time interval;evaluate the write rate against a threshold write rate value within thetime interval; continue the pause of the delta generation request upondetermining that the write rate is at least as high as the thresholdwrite rate value; and resume the delta generation request upondetermining that the write rate is less than the threshold write ratevalue.
 10. The non-transitory CRM of claim 9, wherein the computerreadable program code further enables the computer processor to: monitorthe write rate at which write requests are issued to the storage deviceprior to the pause; and initiate the pause in the delta generationrequest after determining that the write rate is at least as high as thethreshold write rate value.
 11. The non-transitory CRM of claim 9,wherein the computer readable program code further enables the computerprocessor to: continue to monitor the write rate at which write requestsare issued to the storage device after resuming the delta generationrequest; and initiate a second pause in the delta generation requestafter determining that the write rate is at least as high as thethreshold write rate value after resuming the delta generation request.12. The non-transitory CRM of claim 9, wherein resuming the deltageneration request comprises identifying an updated block set in thecollection of block sets relative to a prior time.
 13. Thenon-transitory CRM of claim 12, wherein identifying the updated blockset comprises identifying a transaction group identifier of the updatedblock set.
 14. The non-transitory CRM of claim 9, wherein the pause inthe delta generation request lasts for a period of time that exceeds theinterval of time.
 15. The non-transitory CRM of claim 14, wherein thecomputer readable program code further enables the computer processorto: terminate, after the period of time without resuming the deltageneration request, the delta generation request.
 16. The non-transitoryCRM of claim 9, wherein resuming the delta generation request is basedon receiving a resumption request from the host device after the hostdevice receives a determination that the write rate is less than thethreshold write rate value.
 17. A portable storage device, comprising:persistent storage; and a controller operatively connected to thepersistent storage, and programmed to: monitor, during a pause in adelta generation request received from a host device for the collectionof block sets, a write rate at which write requests are issued to astorage device within a time interval; evaluate the write rate against athreshold write rate value within the time interval; continue the pauseof the delta generation request upon determining that the write rate isat least as high as the threshold write rate value; and resume the deltageneration request upon determining that the write rate is less than thethreshold write rate value.
 18. The portable storage device of claim 17,wherein the portable storage device is a directly-attached storage (DAS)system.
 19. The portable storage device of claim 18, further comprising:a host device directly connected to the portable storage device, whereinthe delta generation request is received from the host device.
 20. Theportable storage device of claim 19, further comprising: a remotestorage system operatively connected to the host device, whereincontents of the collection of block sets are sent to the remote storagesystem for access by the host device.